-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixes for liquid tags #1270
base: master
Are you sure you want to change the base?
fixes for liquid tags #1270
Conversation
…elimiters. Previous tag expansion logic: 2 regexes, 4 calls to regex functions, plus string concatenations. Simplified tag expansion logic: 1 regex + 1 call to re.sub. Support for customizing tag delimiters comes handy when used with plugins with similar tag syntax. E.g. jinja2content.
…the deprecated add(). <rant> The semantics of add() were inverse to the intuition because they were implicitly exposing the internals of markdown.util.Registry. E.g. a priority of ">htmlblock" did not translate to "have greater priority than htmlblock processor", as one would expect. Instead it means "when the interal processors array is sorted by priority, the new processor should have a bigger *index* number than htmlblock". The tricky point here is that the internal array is sorted in reverse. So ">htmlblock" actually translates to "use a smaller priority than htmlblock". Madness! And instead of fixing the semantics to make sense, it was chosen to deprecate add() and force us to directly supply the priority to register(). This is also bad, because we have to grep outside our codebase to determine the proper priority to achieve the desired effect. Double the madness! </rant>
Tests hadn't been updated after 076086c.
This is useful when the live site is hosted in a subdirectory (e.g. http://www.foo.bar/mysite) to avoid having to repeat /mysite every time.
The But I guess we need @mirekdlugosz to chime in here and re-evaluate all these changes. @mirekdlugosz, what should we do with this PR? |
Most of these changes are valuable and I would welcome ported PR in https://github.com/pelican-plugins/liquid-tags There are only two exceptions:
@m000 is this something you are still interested in? Could you re-apply your changes on top of https://github.com/pelican-plugins/liquid-tags and submit PR there? |
Yes, I plan to migrate the PR. I'll try to find some time for it this week.
…On Mon, 8 Feb 2021 at 12:19, Mirek Długosz ***@***.***> wrote:
Most of these changes are valuable and I would welcome ported PR in
https://github.com/pelican-plugins/liquid-tags
There are only two exceptions:
- namespaced plugins were introduced in Pelican 4.5.0, and this is
also version that dropped support for Python 2.7, so I'm afraid anything
related to Python 2 compatibility should be dropped
- fixes to include_code tag I have applied independently while porting
plugin, so they are no longer needed
@m000 <https://github.com/m000> is this something you are still
interested in? Could you re-apply your changes on top of
https://github.com/pelican-plugins/liquid-tags and submit PR there?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1270 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUQQMSBTTAPQ6PG7IIJG3S57CDFANCNFSM4N5F6PCA>
.
|
A bunch of fixes for liquid tags:
py27-ipython3
andpy37-ipython3
. Tests for the notebook tag still fail.Plus a new feature:
{%
and%}
to mark their blocks (e.g. jinja2content).